FM> I've just started to play around with INLINE in TP.
FM> Would you explain in a bit more detail just exactly WHAT
FM> happens when an INLINE sequence is executed?
Sure. First, a general explanation, and then I'll answer your specific questionThere are two uses of Inline in TP - inline statements, and inline procedures/fuHere's an example of an inline statement:
var
i : integer; begin
if i > 1000 then
Inline($CC); end.
What happens here is that the compiler just sticks the byte $CC into the
code stream; nothing else. ($CC is the opcode for a call to the debug interruptso this will make your program stop when i > 1000 if you're in the debugger
or IDE, but
usually does nothing outside it.)
Inline procedures/functions are just a little bit more complicated. An example
of one of those would be:
procedure CallDebugger;
inline($CC);
Now you could code the previous program as
var
i : integer; begin
if i > 1000 then
CallDebugger; end.
and the compiler would generate *exactly* the same code as in the first version.Inline functions/procedures are like macros in assembler or C; they just
expand to an inline statement.
The only twist with inline procedures/functions is that you're allowed to
give them arguments, and allowed to pretend that they're returning values.
For example,
function LongAdd(a,b:word):longint; inline($59/ { pop bx }
$58/ { pop ax }
$31/$d2/ { xor dx,dx }
$01/$d8/ { add ax,bx }
$13/$d2); { adc dx,dx }
If you have an expression like
l := LongAdd(50000,50000);
then this is what happens:
Just as if a regular function was coming, TP pushes the values of the two
arguments onto the stack. Then, instead of making a function call, it just
inserts the LongAdd macro.
The reason this works is as follows. The LongAdd macro first pops the two
arguments from the stack into the AX and BX registers. It then clears the
DX register, adds BX into AX, and if the add overflowed, adds the carry bit
into DX.
The result is that the longint result ends up stored in the register pair
DX:AX. Since that's where longint valued functions are supposed to return
their results, the whole scheme works.
FM> What, for
FM> example is taken care of in BEGIN and END.
BEGIN and END don't have anything to do with INLINE.
FM> Are all of the
FM> registers pushed with BEGIN.
No. Only the BP register (the stack frame pointer) is pushed.
FM> Is there some kind of
FM> popping of registers and then an exit code produced with
FM> END; ?
Yes, the typical code produced by END is something like this:
For functions, move the local result variable into the appropriate registers.
Restore the stack pointer to its value just after pushing BP.
Pop BP.
Return.
FM> Also, is it ever possible to insert TP code into
FM> the MIDDLE of an INLINE sequence?
You can put TP code in between INLINE statements, but you can't put it into
CK> This also makes me wonder, what would happen if I bought TP6.0 and
CK> Borland came out with a new version next week? Would they upgrade for
CK> free? (I think they should). And if I had bought version 6 say, when
CK> it first came out, how much would an upgrade cost?
I don't know what the price would be, but it would almost certainly not be
free. Borland gives free upgrades if you buy after the new product announcementbut not before. No TP 6.0 successor has been officially announced yet, as
far as I
know.
CK> Personally, I believe that upgrades should be very cheap, simply because
CK> the company that developed the software already got your money once.
CK> They probably priced their software assuming that you would buy
CK> only on version. Thus, the price of an upgrade should only cover the
CK> costs of printing, packaging, and distribution. The advantage of a
CK> company doing so would be that 1) we end users would like them a lot
and
CK> tout their products and 2) they could keep old users (and not lose that
CK> share of the market).
In fact, I've heard the economics of it are almost exactly the opposite.
Companies have to do a huge amount of expensive work to get a single new
sale, but it's very easy for them to sell upgrades to current users. They
sell the original aiming
to break even, and make all their money on the upgrades. So I've been told,
JD> For some reason, my program runs fine within TP's IDE. But
JD> when I compile my program to and .EXE file, the nightmare begins...
Generally this signals that you've got an uninitialized variable. You've
been lucky to have it take a good value in the IDE, but aren't so lucky outside.Take a look around for my Clearmem unit (CLEARMEM.ZIP on PDN Pascal); it
helps to find
these errors, by letting you clear memory to a fixed value before each run.
